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A classical method for model-checking timed properties—such as those 
expressed using timed extensions of temporal logic—is to rely on the use of 
observers. In this context, a major problem is to prove the correctness of 
observers. Essentially, this boils down to proving that: (1) every trace that 
contradicts a property can be detected by the observer; but also that (2) 
the observer is innocuous, meaning that it cannot interfere with the system 
under observation. In this paper, we describe a method for automatically 
testing the correctness of realtime observers. This method is obtained by 
automating an approach often referred to as visual verification, in which the 
correctness of a system is performed by inspecting a graphical representation 
of its state space. Our approach has been implemented on the tool Tina, a 
model-checking toolbox for Time Petri Net. 


1 Introduction 

A classical method for model-checking timed behavioral properties—such as those ex¬ 
pressed using timed extensions of temporal logic—is to rely on the use of observers. In 
this approach, we check that a given property, P, is valid for a system S by checking 
the behavior of the system composed with an observer for the property. That is, for 
every property P of interest, we need a pair (Ohsp, fip) of a system (the observer) and 
a formula. Then property P is valid if and only if the composition of S with Obsp, de¬ 
noted (S II Obsp), satisfies fip. This approach is useful when the properties are complex, 

*This work was presented at TTCS 2015, the First IFIP International Conference on Topics in Theoret¬ 
ical Computer Science, August 26-28, 2015. Institute for Research in Fundamental Sciences (IPM), 
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for instance when they include realtime constraints or involve arithmetic expressions on 
variables. Another advantage is that we can often reduce the initial verification problem 
to a much simpler model-checking problem, for example when ijip is a simple reachability 
property. 

In this context, a major problem is to prove the correctness of observers. Essentially, 
this boils down to proving that every trace that contradicts a property can be detected. 
But this also involve proving that an observer will never block the execution of a valid 
trace; we say that it is innocuous or non-intrusive. In other words, we need to assure 
that the “measurements” performed by the observer can be made without affecting the 
system. 

In the present work, we propose to use a model-checking tool chain in order to check 
the correctness of observers. We consider observers related to linear time properties 
obtained by extending the pattern specification language of Dwyer et al. [7] with hard, 
realtime constraints. In this paper, we take the example of the pattern “Present a after 
b within [di,d 2 ['', meaning that event a must occur within di units of time (u.t.) of the 
first occurrence of b, if any, but not later than d 2 - Our approach can be used to prove 
both the soundness and correctness of an observer when we fix the values of the timing 
constraints (the values of di and d 2 in this particular case). 

Our method is not enough, by itself, to prove the correctness of a verification tool. 
Indeed, to be totally trustworthy, this will require the use of more heavy-duty software 
verification methods, such as interactive theorem proving. Nonetheless our method is 
complementary to these approaches. In particular it can be used to debug new or 
optimized definitions of an observer for a given property before engaging in a more 
complex formal proof of its correctness. 

Our method is obtained by automating an approach often referred to as visual ver¬ 
ification, in which the correctness of a system is performed by inspecting a graphical 
representation of its state space. Instead of visual inspection, we check a set of branch¬ 
ing time (modal /r-calculus) properties on the discrete time state space of a system. 
These formulas are derived automatically from a definition of the pattern expressed as 
a first-order formula over timed traces. The gist of this method is that, in a discrete 
time setting, first-order formulas over timed traces can be expressed, interchangeably, 
as regular expressions, LTL formulas or modal /r-calculus formulas. 

This approach has been implemented on the tool Tina |1] , a model-checking toolbox for 
Time Petri Net [12] (TPN). This implementation takes advantage of several components 
of Tina: state space exploration algorithms with a discrete time semantics (using the 
option -FI of Tina); model-checkers for LTL and for modal /r-calculus, called self and 
muse respectively; a new notion of verification probes recently added to Fiacre 13 Ej , one 
of the input specification language of Tina. While model checkers are used to replace 
visual verification, probes are used to ensure innocuousness of the observers. 

1.1 Outline and contributions 

The rest of the paper is organized as follows. In Sect. we give a brief definition of 
Fiacre and the use of probes and observers in this language. In Sect.[^ we introduce the 
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technical notations necessary to define the semantics of patterns and time traces and 
focus on an example of timed patterns. Before concluding, we describe the graphical 
verification method and show how to use a model-checker to automatize the verification 
proces^ 

The theory and technologies underlying our verification method are not new: model¬ 
checking algorithms, semantics of realtime patterns, connection between path properties 
and modal logics, ... Nonetheless, we propose a novel way to combine these techniques 
in order to check the implementation of observers and in order to replace traditional 
“visual” verification methods that are prone to human errors. 

Our paper also makes some contributions at the technical level. In particular, this 
is the first paper that documents the notion of probe, that was only recently added to 
Fiacre. We believe that our (language-level) notion of probes is interesting in its own 
right and could be adopted in other specification languages. 

2 The Fiacre Language 

We consider systems modeled using the specification language Fiacre [31 |S]. (Both the 
system and the observers are expressed in the same language.) Fiacre is a high-level, for¬ 
mal specification language designed to represent both the behavioral and timing aspects 
of reactive systems. 

Fiacre programs are stratified in two main notions: processes, which are well-suited 
for modeling structured activities, and components, which describes a system as a com¬ 
position of processes. Components can be hierarchically composed. We give in Fig. [^a 
simple example of Fiacre specification for a computer mouse button capable of emitting 
a double-click event. The behavior, in this case, is to emit the event double if there are 
more than two click events in strictly less than one unit of time (u.t.). 

2.1 Processes 

A process is defined by a set of parameters and control states, each associated with a set 
of complex transitions (introduced by the keyword from). The initial state of a process 
is the state corresponding to the first from declaration. 

Complex transitions are expressions that declares how variables are updated and which 
transitions may fire. They are built from deterministic constructs available in classical 
programming languages (assignments, conditionals, sequential composition, ...); non- 
deterministic constructs (such as external choice, with the select operator); communica¬ 
tion on ports; and jump to a state (with the to or loop operators). 

For example, in Fig. we declare a process named Push with four communication 
ports (click to delay) and one local boolean variable, dbl. Ports may send and receive 
typed data. The port type none means that no data is exchanged; these ports simply 
act as synchronization events. Regarding complex transitions, the expression related to 


^Code is available at http://www.laas.fr/fiacre/exaniples/visualverif.html 


3 




process Push [click 

none, 

component Mouse 

[click 

: none. 

single 

none, 


single 

: none. 

double 

none. 


double 

: none] i s 

delay 

none] i s 

port delay : 

none in 

[1,1] 


states sO, si, s2 


var dbl : bool := false 


priority delay > click 


from sO click; to si 

from si 
select 

click; dbl := true; loop 
[] delay; to s2 
end 


par 

Push [click, single, double, delay] 
end 


from s2 

if dbl then double 
else single end; 
dbl := false; to sO 


Figure 1: A double-click example in Fiacre 


state si of Push, for instance, declares two possible transitions from si: (1) on a click 
event, set dbl to true and stay in state si; and (2) on a delay event, change to state s2. 

2.2 Components 

A component is built from the parallel composition of processes and/or other compo¬ 
nents, expressed with the operator par Pq || ... || Pn end. In a composition, processes can 
interact both through synchronization (message-passing) and access to shared variables 
(shared memory). 

Components are the unit for process instantiation and for declaring ports and shared 
variables. The syntax of components allows to associate timing constraints with commu¬ 
nications and to define priorities between communication events. The ability to express 
directly timing constraints in programs is a distinguishing feature of Fiacre. For exam¬ 
ple, in the declaration of component Mouse (see Fig. Q, the port statement declares a 
local event delay and asserts that a transition from si to s2 should take exactly one unit 
of time. (Time passes at the same rate for all the processes.) Additionally, the priority 
statement asserts that a transition on event click cannot occur if a transition on delay is 
also possible. 
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2.3 Probes and Observers 


The Fiacre language has been extended, recently, to allow the definition of observers, 
which are a distinguished category of sub-programs that interact with other Fiacre com¬ 
ponents only through the use of probes. A probe is used to observe modifications in the 
system without interfering with it; probes react to the occurrence of an event without 
engaging in it. 

A typical probe declaration is of the form path/obs, where obs denotes the observable 
and path defines its context, that is a path to the component (or process) instance where 
obs is defined (see for example http://www.laas.fr/fiacre/properties.html). In our setting, 
observable events are instantaneous actions involved in the evolution of the system: it 
can be a synchronization over a port p (denoted event p); a process that enters the state 
s (denoted state s); or an expression including shared variables, say exp, that changes 
value (denoted value exp). For instance, in the case of the Mouse component of Fig. a 
probe triggered when the (only instance of) process Push is in state s2 would have the 
form (Mouse/l/state s2). 

The use of probes greatly simplifies the proof of innocuousness of an observer. In par¬ 
ticular, with probes, an observer can only influence a system by “blocking the evolution 
of time”, that is by performing an infinite sequence of actions in finite time. Therefore, 
proving that an observer is innocuous amounts to prove that it has no Zeno behaviors, 
which is always possible when a system is bounded. 


process NeverTwice [a:sync] is 
states idle, once, error 
from idle a ; to once 
from once a ; to error 


component Obs is 
port p:sync is Mouse/event click 
par NeverTwice [p] end 


Figure 2: A simple observer example 


An observer is a Fiacre component where ports are associated to probes (using the 
keyword is); ports associated with a probe have the reserved type sync. We give a naive 
example of observer in Fig. where the component Obs monitors synchronizations on 
the event click. In this example, the process neverTwice will reach the state error if its 
probe parameter, a, is triggered more than once. 

In the remainder of the text, we use the notation (Mouse || Obs) to denote the program 
obtained by concatenating the declaration of these two components (i.e. the code from 
Fig. [^with the code from Fig. [^. As a consequence, we are able to detect if the system 
can emit two single click events just by checking if the process neverTwice can reach the 
state error in (Mouse || Obs). This can be easily achieved using an LTL model-checker 
(the selt tool in our case) with the property [] - (Dbs/l/state error) (meaning that 
never Obs/1 is in state error). 
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3 Timed Traces and First-Order Formulas over Traces 


The semantics of Fiacre (and the properties we want to check) are based on a notion 
of timed traces, which are sequences mixing events and time delays. In this context, a 
“realtime property” can be defined as a set of timed traces, which define timing and 
behavioral constraints on the acceptable execution of a system. In this work, we con¬ 
sider properties derived from realtime patterns, that can be expressed using first-order 
formulas over timed traces. 

3.1 Timed Traces 

In our context, observable events are: communication on a port; the change of state of a 
process; and the change of value of a variable. We use a dense time model, meaning that 
we consider rational time delays and work both with strict and non-strict time bounds. 
Hence a timed trace is a (possibly infinite) sequence of events a,b,... and durations 
5 G Q+: 

a ::= e | aa \ a6 

Given a finite trace a and a—possibly infinite—trace a', we denote a a' the concate¬ 
nation of a and a'. We will also use the expression A(cj) to denote the duration (time 
length) of a trace a. The semantics of a system expressed with Fiacre, say S, can be 
defined as a set JS]] of timed traces. We use the notation cr ^ S when the trace a is in 
the set JS]]. The semantics of a property (timed pattern) will be expressed as the set 
of all timed traces where the pattern holds. We say that a system S satisfies a timed 
requirement P if [[Sj C JP]]. 

3.2 Realtime Properties and their Semantics 

We propose to define properties using First-Order Formulas over Timed Traces (FOTT). 
A FOTT formula ‘h(x), with free variables x = (xi,..., Xn), is a first-order logic formula 
over traces with equality between traces {a = a'), comparison between a duration and 
an interval (A(cj) G I) and concatenation (ct = ui 1 T 2 ). 

d>(T) ::= A I I 3a; . $ | {x = a) \ {x = y z) \ (A(a;) G/) 

For instance, when referring to a timed trace a and an event a, the following formula is 
a tautology if the event a does not occur in a: 

{a ^ a) ^{3 xi,X 2,X3 . {a = X 1 X 2 )/\ {x 2 = axs)) 

Likewise, we can define the “scope” a after b —that determines the part of a trace cr 
located after the first occurrence of b —as the trace a' denoted by the first-order formula: 
3x,y . {a = xy) A {y = ba') A {b ^ x). 

The semantics of a formula d>(a:i,..., Xn) is a set of valuation functions ? associating 
a trace cTj = <^(xi) to each of the variable Xi with i G l..n, also denoted [x* 1 —)■ cri]igi,.„. 
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The semantics of can be defined inductively as follows: 

mx) A ^'(f)]] = [[^(f)]] n [[^'(x)]] [[x = cjJ = {? I ?(x) = a} 

py . ^>(x)J = {? I ? +a] G p(x)]]} {x = y zj = {? p(x) = ?(y) ?(p} 

[[A(x) G /]] = {? I A(?(x)) G 1} 

With these definitions, a regular set of time traces is the set of traces “solutions” of 
an existential FOTT formula with a single free variable, <h(x); that is the set of traces 
a such that the valuation [x i-A it] is in [[d>(x)]]. 

In this paper, we will mainly restrict ourselves to the special case of timed traces 
where events occur at integer dates; i.e. we restrict delays 5 to be in N rather than in 
Q"*". These traces can be generated using a “discrete time” abstraction of the models, 
where special transitions (labeled with t) are used to model the flow of time. Label t 
stands for the “tick” of the logical clock. 

The discrete time semantics will be enough to prove all the properties needed in 
our study. Indeed, when a model contain only “closed timing constraints” (of the kind 
[di, ^ 2 ] or [di, oo[), the discrete time semantics is enough to check reachability properties. 
Actually it is enough to check every formulas in the existential fragment of CTL* without 
next operator [TO] . 

With discrete time, a delay 6 can be replaced by sequences of 6 t’s, and therefore 
a finite timed trace can be simply interpreted as a word. In the remainder, we also 
consider a special symbol, z, that stands for internal actions of the system. Hence it is 
possible to interpret the semantics of (discrete) FOTT specification as a language over 
the alphabet A = {z, t, a, b,.. .}. Actually, in the discrete case, we can show that a 
regular set of time traces is also a regular language. For example, the semantics of the 
formula 3y,z,w . ((x = y z) A {z = aw)) is the regular language corresponding to the 
expression A* ■ a ■ A*. 

This connection between different type of logics is at the core of our approach. Our 
method could be applied to more high-level property languages, such as timed extension 
of temporal logic but would require a more complex encoding into LTL when 
modalities can be nested. 

3.3 Our Running Example: the Present Pattern 

Users of Fiacre have access to a catalog of specification patterns based on a hierarchical 
classification borrowed from Dwyer [7]. Patterns are built from five basic categories— 
existence, absence, universality, response and precedence—and can be composed using 
logical connectives. In each category, generic patterns may be specialized using scope 
modifiers —such as before, after, between—that limit the range of the execution trace 
over which the pattern must hold. Finally, timed patterns are obtained using one of two 
possible kind of timing modifiers that limit the possible dates of events referred in the 
pattern: within I —used to constraint the delay between two given events to be in the 
time interval I —and lasting d —used to constraint the length of time during which a 
given condition holds (without interruption) to be greater than d. 
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Due to limited space, we study only one example of timed pattern, namely Present a 
after b within [di,d 2 [- A complete catalog is available in [T]. This is a simple example 
of existence patterns. Existence patterns are used to express that, in every trace of the 
system, some events must occur. This pattern holds for traces such that the event a 
occurs at a date to after the first occurrence of b with to G [di,d 2 [- The property is 
also satisfied if b never holds. Hence traces a that satisfy this pattern are models of the 
existential FOTT formula: 

Pres(a:) = {b ^ x) V 3y,z,w. {{x = ybzaw) A {b ^ y) A {A{z) G [di,d 2 [)) 

process Present [a:sync, b:sync] is 

states idle, start, watch, error, stop 

from idle b; to start 

from start wait [di, di]; to watch 

from watch select 

a; to stop 
unless 

wait [d 2 —di, •••[; to error 
end 

Listing 1: Observer for the pattern: Present a after b within [di,d 2 [ 

With the discrete semantics, formula Pres(x) matches exactly the words of the form 
tci b r (;2 a wo where wi contains no occurrences of b and W 2 contains exactly k occurrences 
of t with k G [di,d 2 [. (This is a regular language.) We show in the next section how 
to (semi-)automatically generate the regular expression corresponding to such FOTT 
formulas. 

We give an example of observer associated to this pattern in Listing This observer 
is composed of one process that monitors the system through the ports a and b (that 
should be instantiated with the relevant probes). The process is initially in state idle and 
moves to start when b is triggered. When in state start for di unit of time, the observer 
moves to state watch (this is the meaning of the wait operator). The select operator 
is a non-deterministic choice, with unless coding priorities. Hence, in state watch, the 
observer moves to ok if an a occurs, unless a duration equals to (d 2 — di) elapses, in 
which case it moves to the state error. As a consequence, the pattern is false whenever 
the probe (Present/state error) is reachable. Hence the formula associated to the pattern 
is (pp = [] - (Present/state error). 

To prove that an observer Obs for the pattern P is correct, we need to prove that, 
for every system S, the program (S || Obs) satisfies the formula (/)p if and only if [[Sj C 
In m, we have defined a mathematical framework to formally prove these kind 
of properties, but this framework relies on manual proofs and is not supported by any 
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tooling. Efforts are also under way to completely mechanize these proofs using the 
Coq proof assistant [S]. Nonetheless, formal proofs of correctness can be quite tedious. 
Therefore, to detect possible problems with an observer early on (that is, before spending 
a lot of efforts doing a formal proof of correctness) we also rely on a “visual” verification 
method, that is akin to debugging our observers. 

In the next section, we show how to apply the visual verification approach on our 
running example. One of the objective of our work is to replace this visual verification 
step with a more formal approach. This is done in Sect. 

4 Visual Verification of Observers 

In the remainder of this section, we describe the visual verification method using the 
particular case of the pattern Present a after b within [4,5[; we assume that Obs is the 
observer Present defined in Listingthat di = 4 and that d 2 = 5. 

To prove that the observer Present is correct, we need to prove, for every system S, the 
equivalence between two facts: (1) the state (Present/state error) is not reachable in the 
program (S || Present[a, b]); and (2) the traces of P are valid for the property Pres, i.e. 
[SJ C [Pres]]. 

The first step is to get rid of the universal quantification on all possible systems, S, 
that is introduced by our definition of correctness. The idea is to check the observer on a 
particular Fiacre program—called Universal —that can generate all possible combinations 
of delays and events a, b and z. We give an example of universal process in Listing]^ 
The process Universal has only one state and three possible transitions. Each transition 
changes the value of a shared integer variable, x. The first and second transitions of 
Universal can be fired without time constraints. In our context, the probe a will be 
triggered to the event “setting x to 1” and b to “setting x to 2”. The third transition 
reset the value of x to 0 immediately and corresponds to the internal event z. 

We can now use our verification toolchain to generate the state graph for the program 
(Universal || Present) using a discrete time exploration construction. This can be obtained 
using the flag -FI in Tina (it is possible to generate a state graph with many different 
abstractions with Tina, including dense time models). 

The resulting graph is displayed in Fig. This state graph has been generated and 
printed using the tool nd, which is also part of the Tina toolset; nd is an editor and 
animator for extended Time Petri Nets that can export nets and state graphs in several, 
machine readable formats. This graph has only 26 states and can therefore be easily 
managed manually. The main factor commanding the number of states is the value of 
the timing constraints used in the pattern; in our observations, all the generated state 
graphs were of manageable size. 

The transitions in the state graph are also quite straightforward: we find the visible 
and internal transitions as before, labeled with a, b, z and t. For ease of reading, we have 
also changed the labels of internal transitions in the observer Present. For instance, the 
transition from state 2 to 3 corresponds to the observer entering the state start; likewise 
for the transitions labeled with watch, stop and error. The states where the observer is 
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process Universal (&ix : nat) is 
states sO 
from sO select 

X := 1; to sO /* setting x to 1 */ 

[] X := 2; to sO /* setting x to 2 */ 

unless 

on (x<> 0); wait [0,0]; x := 0; to sO 
end 


component Main is 
var X : nat := 0 

port a : sync is value (x = 1), b : sync is value (x = 2) 

par Universal (&5<) || Present [a, b] end 

Listing 2: Universal program in Fiacre 


in state error (the states that contradict the property (pp = [] - (Present/state error)) are 
Errors = {20,22, 23}. 

We can already debug the pattern Present a after b within [4,5[ by visually inspecting 
the state graph. 

For soundness, we need to check that, when the pattern is not satisfied—for traces 
cr that do not satisfy formula Pres—then the observer will detect a problem (observer 
Present eventually reaches a state in the set Errors). 

For innocuousness we need to check that, from any state, it is always possible to reach 
a state where event a (respectively b and t) can fire. Indeed, this means that the observer 
cannot selectively remove the observation of a particular sequence of external transitions 
or the passing of time. 

This graphical verification method has some drawbacks. As such, it relies on a discrete 
time model and only works for fixed values of the timing parameters (we have to fix the 
value of di and ^ 2 )- Nonetheless, it is usually enough to catch many errors in the observer 
before we try to prove the observer correct more formally. 

5 Automating the Visual Verification Method 

A problem with the previous approach is that it essentially relies on an informal inspec¬ 
tion (and on human interaction). We show how to solve this problem by replacing the 
visual inspection of the state graph by the verification of modal /r-calculus formulas, (the 
Tina toolset includes a model-checker for the ;u-calculus called muse.) The general idea 
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Figure 3: State graph for (Universal || Present) 


rests on the fact that we can interpret the state graph as a finite state automaton and 
(some) sets of traces as regular languages. This analogy is generally quite useful when 
dealing with model-checking problems. We start by defining some useful notations. 

5.1 Label Expressions 

Label expressions are boolean expressions denoting a set of (transition) labels. For 
instance, ^ext = (a Vb) denotes the external transitions, while the expression - (a V b Vt) 
is only matched by the silent transition label. We will also use the expression T to denote 
the conjunction of all possible labels, e.g. T = (-b) V b. The model checker muse allows 
the definition of label expressions using the same syntax. 

5.2 Regular (Path) Expressions 

In the following, we consider regular expressions build from label expressions. For exam¬ 
ple, the regular expression t • (- t)* denotes traces of duration 1 with no events occurring 
at time 0. 

Tick = t ■ (-t)* (1) 

We remark that it is possible to define the set of (discrete) traces where the FOTT 
formula Pres holds using the union of two regular languages: (1) the traces where b 
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never occurs, Ri = (- b)*; and (2) the traces where there is an a four units of time 
after the first b. In this particular case, R 2 is a regular expression corresponding to the 
property (x = y b z a rc) A (b ^ y) A (A(z) G [4, 5[ ) 

Pres = (- b)* V R 2 (2) 

R 2 (-b)* • b • (- t)* • Tick ■ Tick ■ Tick ■ Tick • a • T* (3) 

By construction, the regular language associated to Ri V R 2 is exactly the set of finite 
traces matching (the discrete semantics) of Pres. In the most general case, a regular 
expressions can always be automatically generated from an existential FOTT formula 
when the time constraints of delay expressions are fixed (the intervals I in the occurrences 
of (A(x) G I) ). 

The next step is to check that the observer agrees with every trace conforming to 
i? 2 - For this we simply need to check that, starting from the initial state of (Universal || 
Present), it is not possible to reach a state in the set Errors by following a sequence of 
transitions labeled by a word in i? 2 - 

This is a simple instance of a language inclusion problem between finite state au¬ 
tomata. More precisely, if Present is the set of states visited when accepting the traces 
in Ri^ R 2 , we need to check that Errors is included in the complement of the set Present 
(denoted Present). In our example of Fig. we have that Present = {17,20,22,23}, 
and therefore Errors C Present. 

This automata-based approach has still some drawbacks. This is what will motivate 
our use of a branching time logic in the next section. In particular, this method is not 
enough to check the soundness or the innocuousness of the observer. For innocuousness, 
we need to check that every event may always eventually happen. Concerning soundness, 
we need to prove that Errors P Present] which is false in our case. The problem lies in 
the treatment of time divergence (and of fairness), as can be seen from one of the counter¬ 
example produced when we use our LTL model-checker to check the soundness property, 
namely: b. start.z.t .t .t .t .watch.t .t .•• • (ending with a cycle of t transitions). 
This is an example where the error transition is continuously enabled but never fired. 

5.3 Branching Time Specification 

We show how to interpret regular expressions over traces using a modal logic. In this 
case, the target logic is a modal y-calculus with operators for forward and backward 
traversal of a state graph . (Many temporal logics can be encoded in the y-calculus, 
including CTL*). In this context, the semantics of a formula V' over a Kripke structure 
(a state graph) is the set of states where V' holds. 

V’ ::= (pAtjj I “■'0 I <A>V^ | 'tp<A> \ X \ {minX \ i/j) 

The basic modalities in the logic are <A>ip and ^<A>, where A is a label expression. A 
state s is in <A>'ip if and only if there is a (successor) state s' in ijj and a transition from s 
to s' with a label in A. Symmetrically, s is in 'ijj<A> if and only if there is a (predecessor) 
state s' in ■i/’ and a transition from s' to s with a label in A. In the following, we will also 
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use two constants, T, the true formula (matching all the states), and ‘0, that denotes 
the initial state of the model; and the least fixpoint operator min X | ■0 (X) • 

For example, the formula <a>T matches all the states that are the source of an a- 
transition, likewise Reach_a min X | (<a>T V <Z>X) matches all the states that can 
lead to an a-transition using only internal transitions. As a consequence, we can test 
innocuousness by checking that the formula (Reach_a AReach_b AReach_t) is true 
for all states. 

The soundness proof rely on an encoding from regular path expressions into modal 
formulas. We define two encodings: ((i?)) that matches the states encountered while 
firing a trace matching a regular expression R; and ((i?))e that matches the state reached 
(at the end) of a finite trace in R. These encodings rely on two derived operators. (Again, 
we assume here that A is a label expression.) 

Tp o A = Tp<k> 0 * A '= min X | 0 V X<A> 

{{R-A% {{R))eoA {{R-A)) m)v{{R-A% 

m-A*)), m)e*A {{R-A*)) {{R))y{{R.A*)), 

{{R ■ Tick))e = ({{R))e Ot)* (-t) {{R ■ Tick)) = {{R)) V {{R ■ Tick))e 

((i?lVi?2))e = ((i?l))eV((i?2))e ((^1 V i?2)) = {{Rl)) T {{R 2 )) 

{{e))e ‘0 ((e)) '0 

Lemma 1. Given a Kripke structure K, the states matching the formula {{R))e (respec¬ 
tively {{R))) in K are the states reachable from the initial state after firing (resp. all the 
states reachable while firing) a sequence of transitions matching R. 

Sketch. By induction on the definition of R. For example, if we assume that 0 correspond 
to the regular expression R, then ip* A matches all the states reachable from states 
where ip is true using (finite) sequences of transition with label in A; i.e. formula ip * A 
corresponds to R ■ A*. Likewise, we use the interpretation of the empty expression, e, to 
prefix every formula with the constant ‘0 (that will only match the initial state). This 
is necessary since //-calculus formulas are evaluated on all states whereas regular path 
expressions are evaluated from the initial state. □ □ 

For example, we give the formula for ((i? 2 ))e below, where 0oTick stands for the 
expression (0 o t) * (-t): 

((i? 2 ))e '= ‘0 * (“b) o b * (-t) o Tick o Tick o Tick o Tick o a * T 

If Ip Err is a modal //-calculus formula that matches the error condition of the observer, 
then we can check the correctness and soundness of the observer Present by proving that 
the equivalence (EQ), below, is a tautology (that it is true on every states of (Universal 
II Present)). 

((Pres)) AA -ipErr (EQ) 

Again, we can interpret the “error condition” using the //-calculus. The definition of 
errors is a little bit more involved than in the previous case. We say that a state is 
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in error if the transition error is enabled (the formula <error>T is true) or if the state 
can only be reached by firing the error transition (which corresponds to the formula 
(T<error> * T) A ( ‘ 0 * (- error) ). Hence il^Err is the disjunction of these two proper¬ 
ties: 

ijjErr <error>T V ((T<error> * T) A - (‘0 * (-error))) 


The formula (EQ) can be checked almost immediately (less than 1 s on a standard 
computer) for models of a few thousands states using muse. Listing gives a muse 
script file that can be used to test this equivalence relation. 


^ Results are displayed as set of states. Use "output card" to see the cardinality 
output set; 


^ definition of derived operators 

infix X * L =min Y | X VY(L); infix X o L =X(L); 
op TICK X = min Y I X(t) V Y(-t); op NEVER L = ('0) * (-L); 
op EXT = a Vb Vt; # labels of the external transitions 
op REACH L = min X I ((L)T) V (-EXT)X; 

# INNOCUOUSNESS 

op Innocuous = (REACH a) A (REACH b) A (REACH t); 

# SOUNDNESS 


op AO = (NEVER b) o b; 
op A1 = A * (—t); 
op A2 =TICK(A1); 
op A3 =TICK(A2); 
op A4 =TICK(A3); 
op A5 =TICK(A4); 
op A6 = A5 o a; 
op A7 = A6 * T; 


op SO = (NEVER b) VAO; 
op SI = SO V Al; 
op S2 = SI V A2; 
op S3 = S2 V A3; 
op S4 = S3 V A4; 
op S5 = S4 V A5; 
op S6 = S5 V A6; 
op S7 = S6 V A7; 


op Rl= NEVER b; opR2=S7 

op Pres = R1 V R2; 

op ERRORS = (error)T V (((T(error)) * T) A — ((‘0) * (—error))); 


Pres <tA (— ERRORS); ^ this is a tautology if all the states are listed 


Listing 3: Script file for muse to check that ((Pres)) <tA —ipErr is a tautology 
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6 Related Work and Conclusion 


Few works consider the verification of model-checking tools. Indeed, most of the existing 
approaches concentrate on the verification of the model-checking algorithms, rather than 
on the verification of the tools themselves. For example, Smaus et al. provide 
a formal proof of an algorithm for generating Biichi automata from a LTL formula 
using the Isabelle interactive theorem prover. This algorithm is at the heart of many 
LTL model-checker based on an automata-theoretic approach. The problem of verifying 
verification tools also appears in conjunction with certification issues. In particular, 
many certification norms, such as the DO-178B, requires that any tool used for the 
development of a critical equipment be qualified at the same level of criticality than the 
equipment. (Of course, certification does not necessarily mean formal proof!) In this 
context, we can cite the work done on the certification of the SCADE compiler US], a 
tool-suite based on the synchronous language Lustre that integrates a model-checking 
engine. Nonetheless, only the code-generation part of the compiler is certified and not 
the verification part. 

Concerning observer-based model-checking, most of the works rely on an automatic 
way to synthesize observers from a formal definition of the properties. For instance, Aceto 
et al. [2] propose a method to verify properties based on the use of test automata. In 
this framework, verification is limited to safety and bounded liveness properties since the 
authors focus on properties that can be reduced to reachability checking. In the context 
of Time Petri Net, Toussaint et al. m also propose a verification technique based on 
“timed observers”, but they only consider four specific kinds of time constraints. None 
of these works consider the complexity or the correctness of the verification problem. 
Another related work is [2] , where the authors define observers based on Timed Automata 
for each pattern. Our approach is quite orthogonal to the “synthesis approach”. Indeed 
we seek, for each property, to come up with the best possible observer in practice. To 
this end, using our toolchain, we compare the complexity of different implementations 
on a fixed set of representative examples and for a specific set of properties and kept 
the best candidates. The need to check multiple implementations for the same patterns 
has motivated the need to develop a lightweight verification method for checking their 
correctness. 

Compared to these works, we make several contributions. We define a complete verifi¬ 
cation framework for checking observers with hard realtime constraints. This framework 
has been tested on a set of observers derived from high-level timed specification patterns. 
This work is also our first public application of the probe technology, that was added to 
Fiacre only recently. To the best of our knowledge, the notion of probes is totally new 
in the context of formal specification language. Paun and Chechik propose a somewhat 
similar mechanism in inuni — in an untimed setting—where they define new categories 
of events. However our approach is more general, as we define probes for a richer set of 
events, such as variables changing state. We believe that this (language-level) notion of 
probes is interesting in its own right and could be adopted by other formal specification 
languages. Finally, we propose a formal approach that can be used to gain confidence 
on the implementation of our model-checking tools and that replaces traditional “visual 
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verification methods” that are prone to human errors. This result also prove the useful¬ 
ness of having access to a complete toolbox that provides different kind of tools: editors, 

model-checkers for different kind of logics, ... 
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